Snapshot and restore

Amazon ElastiCache caches running Redis can back up their data by creating a snapshot. You can use the backup to restore a cache or seed data to a new cache. The backup consists of the cache’s metadata, along with all of the data in the cache. All backups are written to Amazon Simple Storage Service (Amazon S3), which provides durable storage. At any time, you can restore your data by creating a new Redis cache and populating it with data from a backup. With ElastiCache, you can manage backups using the AWS Management Console, the AWS Command Line Interface (AWS CLI), and the ElastiCache API.

If you plan to delete a cache and it's important to preserve the data, you can take an extra precaution. To do this, create a manual backup first, verify that its status is available, and then delete the cache. Doing this makes sure that if the backup fails, you still have the cache data available. You can retry making a backup, following the best practices outlined preceding.

Consider the following constraints when planning or making backups:

Backup and restore are supported only for caches running on Redis or Serverless Memcached.

For Redis (cluster mode disabled) clusters, backup and restore aren't supported on cache.t1.micro nodes. All other cache node types are supported.

For Redis (cluster mode enabled) clusters, backup and restore are supported for all node types.

During any contiguous 24-hour period, you can create no more than 24 manual backups per serverless cache. For Redis self-designed clusters, you can create no more than 20 manual backups per node in the cluster.

Redis (cluster mode enabled) only supports taking backups on the cluster level (for the API or CLI, the replication group level). Redis (cluster mode enabled) doesn't support taking backups at the shard level (for the API or CLI, the node group level).

During the backup process, you can't run any other API or CLI operations on serverless cache. You can run API or CLI operations on a self-designed cluster during backup.

If using caches with data tiering, you cannot export a backup to Amazon S3.

You can restore a backup of a cluster using the r6gd node type only to clusters using the r6gd node type.

Backups on serverless caches are transparent to the application with no performance impact. However, when creating backups for self-designing clusters, there can be some performance impact depending on the available reserved memory. Self-designed clusters are not available with ElastiCache and Memcached, but are available with ElastiCache and Redis.

The following are guidelines for improving backup performance for self-designed clusters.

Set the reserved-memory-percent parameter – To mitigate excessive paging, we recommend that you set the reserved-memory-percent parameter. This parameter prevents Redis from consuming all of the node's available memory, and can help reduce the amount of paging. You might also see performance improvements by simply using a larger node. For more information about the reserved-memory and reserved-memory-percent parameters, see Managing Reserved Memory.

Create backups from a read replica – If you are running Redis in a node group with more than one node, you can take a backup from the primary node or one of the read replicas. Because of the system resources required during BGSAVE, we recommend that you create backups from one of the read replicas. While the backup is being created from the replica, the primary node remains unaffected by BGSAVE resource requirements. The primary node can continue serving requests without slowing down.

To do this, see Creating a manual backup (Console) and in the Cluster Name field in the Create Backup window, choose a replica instead of the default primary node.

If you delete a replication group and request a final backup, ElastiCache always takes the backup from the primary node. This ensures that you capture the very latest Redis data, before the replication group is deleted.